Viren zu schreiben, die solche Sicherheitslücken ausnutzen, setzt jedoch tieferes Know-how voraus. Skript-Kiddies – also Jugendliche, die sich irgendeines fertigen Skripts zum Hacken bedienen – können da weniger Schaden anrichten. Aber gerade weil versierte Hacker sehr genau wissen, was sie tun, entstehen gefährliche Attacken. Solche Viren richten sich häufiger gegen Webserver oder Datenbanken als gegen Heim-PCs: Im Gegensatz zu Blaster hat Code Red den Internet Information Server attackiert, Slammer setzte sich in SQL-Datenbanken fest. Die Schädlinge treffen also wirtschaftlich relevante Bereiche wie Internet-Shops.

Das Verblüffende daran: Der Buffer Overflow ist eine der ältesten Angriffs-Methoden. Bereits im Jahr 1996 gab es eine Dokumentation zum Thema.

Warum treten in fast jedem Code solche Lücken auf?
Ein Grund: Die Programme werden umfangreicher. Immer mehr Menschen sind beteiligt. So entstehen zwangsläufig Fehler, die selbst bei gründlichen Checks nicht auffallen. Das passiert bei Software-Schmieden wie Microsoft ständig, doch auch Unternehmen wie die Weltraum-Behörde ESA sind nicht davor gefeit. So sprengte sich 1996 eine Ariane-Rakete selbst, weil das Programm einen Fehler aufwies, der einem Buffer Overflow ähnelte. Die ESA verlor über eine halbe Milliarde Euro.

Das passiert beim Buffer Overflow:
Entscheidend ist die Art, wie Routinen und Variablen abgelegt werden: Jedes Programm, das ausgeführt wird, findet man zu Beginn des Arbeitsspeichers, während Variable – also Daten, die im Betrieb generiert werden – am Ende gespeichert sind. Dieses zweite Segment heißt Stack.

Codes, die öfter genutzt werden, legen Programmierer in Unterroutinen ab, die die Anwendung bei Bedarf aufruft. Nach Ausführen einer Subroutine springt der Prozessor zurück ins Haupt-Programm. Dafür benötigt er vom Stack die vorher abgelegte Rücksprungadresse. Und hier passiert es: Hat der Programmierer für eine Variable einen zu kurzen Speicherbereich (Buffer) reserviert, kann es vorkommen, dass der Inhalt eine Rücksprungadresse überschreibt – der Sprung gelingt nicht, ein Absturz folgt.

Ein Hacker gibt sich mit dem Absturz nicht zufrieden. Er ermittelt, wie viele Daten er in eine ungeprüfte Variable schreiben muss, um eine andere Variable mit eigenen Daten zu füllen. Besonders interessant ist die Rücksprungadresse. Schafft es der Hacker, sie sinnvoll zu überschreiben, kann er den Programmfluss umlenken und auf den Anfang des Codes eines Trojaners zeigen.